The present invention relates to computer systems. More specifically, the invention relates to verifying input/output command data.
Early on in the development of computer systems, it became apparent that it would be advantageous, if not necessary, to store data on persistent storage, such as hard drives. The benefits and advancements (e.g., increased storage capacity and speed) in persistent storage have been a significant reason that computer systems have become so successful over the years.
Occasionally, however, design faults or hardware failures result in the wrong data being transferred to the persistent storage. This can be the result of software failures in the memory manager of the operating system not providing the correct physical address the memory. Also, a failure in the host bus adapter can result in using the data intended for another input/output (I/O) command. Additionally, a switch on the storage area network (SAN) could misroute the data or command. There are many other possible failures that can result in the wrong data being stored on the storage device (e.g., disk drive). With current technology, this failure is not noticed until the data is read from the storage device. By then, however, it is too late to take any corrective action so the data is lost. Furthermore, the previous version of the data is also lost.
One solution is to reread the data after every write and verify that it is correct. In many systems, this will not detect a significant proportion of the failures because the reread will get the data from the nearest cached copy of the data rather than from the persistent storage. The failure can be in the transfer from the cached copy to the persistent storage, which would not be detected. If rereading does go all the way to the storage, then the cost of every write is doubled. This is why it is not common for applications to issue rereads after writes.
Another solution is to mandate that all the blocks that are stored on the persistent storage (or logical partition thereof) have a common format. For example, each block can be the same size and have a block number and checksum in known locations in the block. This way, the persistent storage can verify the block number and/or the checksum of a block before it is written. Although this solution can work well in some situations, it has some drawbacks. By mandating that all the blocks on the storage device have the same format, it maybe be difficult, if not impossible, to mix blocks from different applications on the same storage device. Also, it may require coordination of product updates to both the storage and the application to introduce a new block format.
It would be beneficial to have improved techniques for verifying I/O command data. Additionally, it would be beneficial to have innovative techniques for verifying that the data that is intended to be written to a storage device is the data that is actually going to be written.